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L'invention concerne une architecture de terminal, plus particulierement 
un terminal du type mettant en ceuvre un clavier et un lecteur de carte a puce 
situes dans une enceinte securisee, et destine a communiquer avec un serveur, 
via un reseau de type Internet. 
5 Un tel dispositif est connu, par exemple, sous la denomination 

commerciale "safepad". 

Dans le cadre de Tinvention, le terme "terminal" doit etre compris dans 
un sens general. Le terminal precite peut etre notamment constitue par un 
ordinateur personnel fonctionnant sous divers systemes d*exploitation, tels 
10 WINDOWS ou UNIX (tous deux etant des marques deposees). II peut etre aussi 
constitue par une station de travail, un ordinateur portable ou un terminal de 
carte dit dedie. 

De meme, dans le cadre de l'invention, le terme "reseau Internet" 
englobe, outre le reseau Internet proprement dit, les reseaux prives 
15 d'entreprises ou similaires, dits "intranet", et les reseaux les prolongeant vers 
I'exterieur, dits "extranet". 

Les cartes a puce sont utilisees dans divers domaines : applications 
bancaires, de sante, comme "porte-monnaie" dit electronique, etc. Sur une carte 
a puce peuvent en outre coexister plusieurs applications (carte a puce multi- 
20 application). 

Pour ces types d'applications, les carte a puce peuvent se voir 
devolues diverses fonctions. En particulier, elles peuvent etre utilisees a des 
fins de securite. Le terme "securite" doit etre compris dans un sens general : 
notamment confidentialite et/ou authentification de i'utilisateur de la station et/ou 
25 du proprietaire de la carte a puce elle-meme. 

Dans ce cadre plus particulier d'applications, le terminal peut etre muni 
d'une enceinte securisee comprenant un lecteur de carte a puce, un clavier et 
eventuellement une ou plusieurs autres ressources informatiques. 

La figure 1 illustre tres schematiquement I'architecture d'un terminal du 
30 type precite, selon I'art connu. 

Pour fixer les idees, on va supposer que le terminal 1 est constitue a 
base d'un micro-ordinateur. Celui-ci est muni de tous les organes habituels 



constitutifs de tels appareils informatiques et necessaires a leur bon 
fonctionnement (et qui n'ont pas ete representes) : unite centrale, memoire vive, 
memoire de masse (disque dur). lecteur(s) de support d'information (disquettes, 
etc.), etc. Dans le cas particulier illustre sur la figure 1, le terminal 1 est muni 

5 d'une enceinte securisee 3 comprenant un lecteur 30 de carte a puce 2 et un 
clavier 31. Le clavier 31 sert notamment a la saisie de donnees 
d'authentification du possesseur de la carte a puce 2 : par exemple un mot de 
passe associe a un identifiant de la carte a puce 2. Divers circuits electroniques 
permettent une communication entre les elements securises presents dans cette 

10 enceinte, notamment le clavier 31 et la carte a puce 2 (via le lecteur 30). d'une 
part, et ces elements securises et les elements non securises presents dans le 
terminal 1, d'autre part. 

Habituellement. le terminal comprend, dans sa partie non securisee, 
une application specifique 10, que Ton appellera ci-apres "marchande", assurant 

15 la gestion et le controle de transactions particulieres permises par le terminal 1 
en question. Les communications entre cette application 10 et les elements 
internes a I'enceinte securisee 3 s'effectuent habituellement selon un standard 
du type "RS232"; Les communications entre les elements internes a I'enceinte 
securisee 3, notamment une application residente 300, et la carte a puce 2, via 

20 le lecteur 30, s'effectuent habituellement selon un protocole obeissant aux 
normes ISO 7816-1 a 7816-4. 

Ce type d'architecture presente done comme premiers inconvenients, 
notamment les suivants : 

- I'application marchande implantee dans le terminal (partie non securisee) et 
25 celle residente dans I'enceinte securisee sont specif iques a ce terminal ; 

- les programmes informatiques associes sont en general volumineux ; et 

- la souplesse et la fiabilite sont limitees, car une modification de ces 
programmes necessite un rechargement de programmes dans le terminal 
(partie non securisee) et dans I'enceinte securisee, ainsi qu'eventuellement 

30 I'execution de tests de bon fonctionnement, ce qui necessite la presence de 

personnel specialise. 
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Generalement, cette derniere operation doit etre repetee pour un grand 
nombre de terminaux. 

II doit en outre etre conserve a Tesprit qu'il s*agit d'applications en tout 
ou partie securisees. On doit done pouvoir garantir, pour la mise a jour de 
5 programmes, un niveau de securite determine, propre a rapplication specifique. 

Le plus souvent, le terminal 1 n'est pas isole, en ce sens qu'il est relie. 
via un reseau de transmission R/, a un ou plusieurs systemes eloignes, dont un 
seul 4 a ete illustre sur la figure 1 . La nature du reseau Rl peut etre tres diverse, 
selon les applications envisagees (application bancaire, de sante, etc). II peut 

10 s'agir notamment du reseau Internet ou d'un reseau de ce type (intranet ou 
extranet), compte tenu du developpement rapide de ce dernier type de reseau et 
des applications qui y font appel. De fa^on habituelle, I'architecture globale est 
du type dit "client-serveur", le "serveur" etant generalement le systeme eloigne 4 
et le "client" etant le terminal 1. Mais dans certaines circonstances, les roles 

IS peuvent etre inverses ou alternes pendant le temps d'une transaction. 

Dans une telle architecture, les programmes associes a Tapplication 
specifique 10 et a ['application 300, en presence d'une modification de leur 
version, pour quelle que raison que ce soit, peuvent alors etre mis a jour de 
fagon centralisee, a partir d'un des serveurs eloignes, par exemple le serveur 4. 

20 II s'ensuit qu*un des inconvenients signales peut etre attenue, la mise a jour 
etant effectuee par teletraitement. Ces operations necessitent cependant la 
mise en oeuvre de procedures d'administration bien rodees. En outre, le 
telechargement peut comprendre des donnees sensibles ou pour le moins ne 
doit pas autoriser Timpiantation dans le terminal de programmes et/ou 

25 procedures non autorises ou dangereux pour la securite ("cheval de Troie", 
"bombes logiques", virus, etc.). 

En outre, avec la montee en puissance et Tuniversalite du reseau 
Internet, le besoin se fait sentir de "faire migrer" les applications specifiques 
precitees, implantees localement dans les terminaux, vers les serveurs eloignes, 

30 que Ton appellera ci apres "serveurs marchands", d*une part, et de dialoguer 
directement avec la carte a puce, a partir de ces serveurs marchands, d'autre 
part. 
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Ce second besoin, en particulier, ne peut etre satisfait par les terminaux 
de Tart connu, pour des raisons qui vont etre explicitees ci-apres. 

Mais tout d*abord, il paraTt utile de decrire brievement une architecture 
de systeme permettant la communication entre un terminal selon I'art connu et 
5 un serveur eloigne, via un reseau de type Internet RL Une telle architecture est 
representee schematiquement sur la figure 2, figure sur laquelle a ete 
representee plus particulierement {'architecture logique du terminal, 
reference 1'. 

Le terminal V est ici un terminal d'un type general, securise ou non, 

10 cette disposition n'etant pas importante pour expliciter les differents types de 
communications en cause. 

Comma il a ete indique precedemment, le terminal 1' comprend 
naturellement tous les circuits et organes necessaires a son bon 
fonctionnement, et qui n'ont pas ete representes dans un but de simplification 

15 du dessin. Habituellement, le terminal 1' est aussi relie a des peripheriques 
classiques, integres ou non, tels un ecran de visualisation (non represente) et 
un clavier 31, situe dans une enceinte securisee (figure 1 : 3) dans le cadre plus 
particulier de Tinvention. 

Habituellement, les communications sur les reseaux s'effectuent 

20 conformement a des protocoles repondant a des standards comprenant 
plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de type 
Internet, les communications s'effectuent selon des protocoles specifiques a ce 
type de communication, mais qui comprennent aussi plusieurs couches 
logicielles. Le protocole de communication est choisi en fonction de I'application 

25 plus particulierement visee : interrogation de pages "WEB", transferts de 
fichiers, courrier electronique (e-mel, ou "e-mail" selon la terminologie anglo- 
saxonne), forums ou "news", etc. 

L'architecture des reseaux de communication est decrite par diverses 
couches. A titre d'exemple. le standard "OSI" ("Open System Interconnection"), 

30 defini par 1' "ISO", comporte sept couches qui vont des couches dites basses 
(par exemple la couche dite "physique" qui concerne le support de transmission 
physique) aux couches dites hautes (par exemple la couche dite "d'application"), 
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en passant par des couches intermediaires, notamment la couche dite de 
"transport". Une couche donnee offre ses services a la couche qui lui est 
immediatement superieure et requiert de la couche qui lui est immediatement 
inferieure d'autres services, via des interfaces appropriees. Les couches 
5 communiquent a I'aide de primitives. Elles peuvent egalement communiquer 
avec des couches de meme niveau. Dans certaines architectures, Tune ou 
I'autre de ces couches peut etre inexistante. 

Dans un environnement Internet, les couches sont au nombre de cinq, 
et de fa^on plus precise, en allant de la couche superieure a la couche 

10 inferieure : la couche d'applications ("http", "ftp", "e-mail", etc.), la couche de 
transport ("TCP"), la couche d'adressage de reseau ("IP"), la couche de liens de 
donnees ("PPP", "Slip", etc.) et la couche physique. 

Le terminal 1' comprend des circuits d'acces 11 au reseau Internet. II 
peut s'agir d*un modem pour se connecter a une ligne telephonique commutee 

15 OU a un reseau numerique a integration de services ("RNIS"). via par exemple 
un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). Les circuits 11 d'acces au reseau Rl regroupent 
les couches logicielles inferieures Ci et C2, correspondant aux couches 
"physique" et de "lien de donnees" precitees. 

20 On a egalement represents les couches superieures C3 et C4, 

correspondant aux couches "d'adressage de reseau" ("IP") et de "transport" 
("TCP"). La couche superieure d'application ("http", "ftp", "e-mail", etc.) est 
schematisee par un navigateur "WEB" NW de type quelconque, de preference 
d'un type standard du commerce. 

25 L'interface entre les couches inferieures, Ci et C2, et les couches 

superieures, C3 et C4, est constituee par une couche logicielle 15 generalement 
appelee "driver couches basses". Les couches superieures, C3 C4. 
s'appuient sur cette interface et sont mises en oeuvre par I'intermediaire de 
bibliotheques de fonctions specifiques ou bibliotheques reseau 14, avec 

30 lesquelles elles correspondent. Dans le cas du reseau Internet, "TCP/IP" est mis 
en oeuvre au moyen de bibliotheques dites de "sockets". 



Cette organisation permet au navigateur NW de poser des requetes 
vers un serveur eloigne 4, pour la consultation de pages ""WEB"" 
(protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou renvoi de 
courrier electronique (protocole "e-mail"). 

Le terminal 1' comprend egalement le lecteur de carte 30 situe dans 
une enceinte securisee (figure 1 : 3), dans le cadre plus particulier de 
rinvention. Pour communiquer avec la carte a puce 2, le lecteur de carte 30 
englobe egalement deux couches basses, CCi (couche physique) et CC2 
(couche de lien de donnees), jouant un role similaire aux couches Ci et C2 Les 
interfaces logicielles avec les couches CCi CC2 sont decrites, par exemple. 
par la specification "PC/SC" ("part 6, service provider"). Les couches elles- 
memes. CCi et CC2i sont notamment decrites par les normes ISO 7816-1 
a 7816-4. 

Une couche logiejelle supplementaire 13 forme interface entre des 
couches applicatives, sous la reference unique Applh, et les couches 
inferieures, CCi et CC2.vLa fonction principale devolue a cette couche 13 est 
une fonction de multipiexage/demultiplexage: 

Du cote de la carte^ a puce 2, on retrouve une organisation similaire. a 
savoir la presence de deux couches basses, referencees CC'1 (couche 
physique) et CC'2 (couche de lien de donnees), ainsi qu'une couche 
d'interface 23. tout a fait similaire a la couche 13. Cette couche 23 assure une 
interface entre les couches protocolaires CC'1 et CC'2 precitees et une ou 
plusieurs couches applicatives, representees sous la forme d'un module unique 
referencee /\pp//2. 

Les communications entre le lecteur de carte a puce 30 et la carte a 
puce 2 s'effectuent a I'aide de commandes standardisees. connues sous 
I'abreviation-anglo-saxonne-de "APDU" (pour "Application^Protocol Data Unit"). 

Differents protocoles sont utilisables, et a titre d'exemples non 
exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole defini par la norme ISO 7816-3, en mode caractere T=0 ; 
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le protocole defini par la norme ISO 7816-3, en mode bloc T=1 ; 
ou le protocole defini par la norme ISO 3309, en mode trame "HDLC" 
(pour "High-Level Data Link Control procedure" ou procedure de commands 
de liaison a haul niveau). 
5 Dans le cadre de i'lnvention, on utilisera de preference le protocole 

ISO 7816-3, en mode bloc. 

De fagon connue en soi, a chaque couche de protocole, il est associe 
un certain nombre de primitives qui permettent les echanges de donnees entre 
couches de meme niveau et d'une couche a I'autre. 
10 Dans I'etat actuel de la technique, il n'est pas possible de mettre en 

communication directe la carte a puce 2 avec un serveur eloigne 4, via le reseau 
Internet R/. car le protocole de communication entre une carte a puce 2 d'un 
type standard, qui vient d'etre rappele. est incompatible avec ceux utilises sur le 
reseau Internet ou tout reseau de ce type. II n'est pas non plus possible d'etablir 
15 des communications directes entre le navigateur A/lVet la carte a puce 2, sauf a 
implanter dans le navigateur NW une piece de logiciel, dit "plug-in", d'un type 
specifique. 

Si on se reporte de nouveau a la figure 1, en supposant que le 
terminal 1 est relie au reseau Internet, et en resume de ce qui vient d'etre 

20 rappele, on constate que ce terminal 1, selon Tart connu, comprenant une 
enceinte securisee 3 munie d'un clavier 31 et d'un lecteur 30 de carte a puce 2, 
comporte deux interfaces principales de communication, Si et S2, representees 
en traits pointilles. Une premiere interface, Si, relie I'enceinte 3 au terminal 1 
proprement dit, ou s'execute I'application marchande 10, et une deuxieme 

25 interface, S2, est prevue pour les communications avec la carte a puce 2. En 
realite, Tinterface S2 est repartie entre I'application 300 et la carte a puce 2. A 
ces deux interfaces s'ajoute en outre interface vers I'exterieur (figure 2 : 
circuits 1 1 notamment), qui permet au terminal 1 de communiquer avec le 
reseau Internet Rl. L'interface S^ accepte deux niveaux de dialogue : un premier 

30 dialogue transparent pour lequel un ordre emis par le terminal 1 s'execute sans 
modification semantique par interface S2, et un second niveau de dialogue qui 
fait intervenir I'application 300. 
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Ainsi Tauthentification par saisie de mot de passe sur le clavier 31 est 
un ordre soumis a I'interface Si qui est interprete par I'application 300 et 
transforme en une succession d'echanges sur I'interface S2, entre I'application 
300 et la carte a puce 2. Le resultat de ces echanges est transmis a 
5 I'interface Si. 

Outre le fait, qu'il est exclu, dans I'etat actuel de la technique, qu'une 
carte a puce standard 2 accepte des echanges directs avec le reseau 
Internet Rl, comme 11 vient d'etre rappele. I'inconvenient majeur des terminaux 
selon Tart connu est constitue par la presence de I'application residente 300. II 

10 s'agit le plus souvent d'une application dite "proprietaire", ce qui implique que 
Tapplication marchande 10 doit etre ecrite en fonction de la nature et du type de 
terminal utilise. Elle est done a priori differente d'un type de terminal a un autre, 
ce qui ne facilite pas les operations de maintenance. En outre, elle n'est pas 
non plus adaptee a un environnement de type internet.- 

IS II a ete propose des standards pour des applications du type de celle de 

rinvention. comme le standard connu sous le sigle. anglo-saxon "OCF" (pour 
"Open Card Framework") qui .tend a la standaridisation des echanges entre le 
terminal ^marehand 1 et le lecteur 30 deucaRte^^a ^puce 2, en respectant par 
exemple la norme "EMV" des terminaux. Cependant un tel standard n'est pas 

20 directement utilisable dans un contexte Internet. 

Est egalement connu. dans le domaine des applications bancaires, le 
protocole dit "C-SET", protocole defini par le CLE. carte bancaire. Selon ce 
protocole. un utilisateur se connecte sur un site marchand disponible sur 
le "WEB" et precede a un achat. Ce dernier, lors de la transaction, sollicite des 

25 elements de I'enceinte securisee pour authentifier le porteur de la carte bancaire 
effectuant I'achat. Cette authentification est effectuee par Texecution d'un 
logiciel dans le terminal (partie non securisee) et I'enceinte. 

Ce protocole n'est pas non plus exempt d'inconvenients : 

- il rend necessaire la presence d'un logiciel specifique dans le terminal 
30 et dans Tenceinte ; 

- il rend necessaire la certification des logiciels imposes par "C-SET" ; 



- le protocole "C-SET" est uniquement oriente paiement : le logiciel dans 
le terminal qui traite las Informations du serveur "WEB" et du paiement par la 
carte bancaire est un logiciel de paiement. 

Par ces caracteristiques, il ne differe guere des solutions de I'art connu 
precedemment evoquees. II ne permet pas des communications de bout en 
bout, selon un protocole de type Internet, notamment un adressage direct de la 
carte a puce. De par sa specificite, il n'offre aucune flexibilite et n'est pas adapte 
pour una utilisation dans d'autras domaines : sante, mise a jour de donnees 
stockees sur une carte a puce, credit de points, etc. 

Tout en palliant les inconvenients des precedes et architectures de I'art 
connu, at dont certains viennent d'etre rappeles. I'invention se fixe pour but de 
remplir les besoins qui se font sentir. 

Elle favorise I'utilisation sur le reseau Internet de terminaux comprenant 
une enceinte securisee munie d'au moins un lecteur de carte a puce et d'un 
clavier, en permettant la migration des applications des lecteurs de carte a puce 
et des terminaux vers un serveur eloigne de type "WEB", d'une part, et le 
dialogue direct avec la carte a puce, d'autre part. 

Elle permet une mise a jour ou un ajout de logiciel interne a I'enceinte 
securisee, avec un maximum de securite. 

Pour ce faire. selon un premier aspect important de I'invention. la carte 
a puce n'est plus adressee de fagon classique par des "APDU", conformement 
au protocole de communication ISO 7816 precite, mais par utilisation d'une 
adresse "URL" (pour "Universal Resource Location"). Comme il est connu, une 
adresse "URL" est constituee d'une adresse "IP" proprement dita et d'un numero 
de port. De la meme maniere. I'enceinte securisee utilise cat adressage 
par "URL". 

Selon un aspect important de I'invention, la carte a puce se comporte 
done aussi comme un serveur et/ou client "WEB". 

L'enceinte securisee selon I'invention est "transparente" pour le reseau 
Internet, en ce sens que les "ordres carte" emanant du serveur marchand 
eloigne ne font pas intervenir d'elements d'adressage du terminal. II s'ensuit que 
les ressources associees a I'enceinte securisee ne sont pas accessibles du 
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reseau Internet. Par contra, les applications contenues dans la carte a puce ont 
la possibilite d'adresser et d'activer toutes les ressources informatiques 
presentes dans I'enceinte securisee, notamment un clavier, par simple 
adressage "URL" comme il sera explicite ci-apres. 
5 Pour ce faire, le terminal comprend physiquement : 

- une enceinte securisee d'un type modifie, comprenant au moins un 
lecteur de carte a puce et un clavier (et/ou une autre ressource informatique), 
tous deux rattaches a un serveur "HTTP" dit d'enceinte securisee. ainsi qu*une 
unite d'execution qui gere I'ensemble des ressources presentes dans i'enceinte ; 

10 et 

- outre des elements classiques (memoires, etc.) et un navigateur de 
type "WEB", un premier noeud de communication, dit de terminal, assurant des 
communications entre le reseau Internet, le navigateur de type "WEB" et/ou 
I'enceinte securisee. 

15 Par ailleurs, I'enceinte securisee precitee comprend un deuxieme noeud 

de communication, dit d'enceinte, assurant des communications entre le 
terminal proprement dit, via le premier noeud de communication, le serveur 
"HTTP" dit d'enceinte securisee, et/ou le lecteur de carte a puce. 

La carte a puce est elle-meme munie d'un troisieme noeud de 

20 communication, dit de carte, et d'une adaptation logicielle se comportant comme 
un serveur "HTTP", formant interface entre au moins une application residents 
dans la carte a puce et le deuxieme noeud de communication. 

Le premier noeud de communication aiguille les requetes du reseau 
Internet ayant un numero de port associe a I'enceinte securisee vers cette 

25 enceinte et effectue les adaptations de protocoles necessaires pour mettre en 
communication directe le reseau Internet avec le deuxieme noeud de 
communication, et assurer une propagation d'informations et/©u d'ordres vers la 
carte a puce. 

Pour certaines applications, notamment des applications exigeant un 
30 haut niveau de securite, I'enceinte securisee peut comprendre 
avantageusement une ou plusieurs ressource(s) informatique(s) 
supplementaire(s), tels par exemple des dispositifs d'authentification 
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biometriques (reconnaissance oculaire, vocale et/ou de signature), un 
coprocesseur ou un interpreteur externe. 

Dans una variants preferee du precede selon I'invention, les 
programmes necessaires au fonctionnement des elements et ressources de 
5 Tenceinte securisee, ou leurs mises a jour, sont telecharges, via le reseau 
Internet, depuis un serveur "WEB" distant relie a ce reseau. La mise a jour peut 
inclure Teffacement, au moins partiel de ces programmes. 

On prevoit egalement, dans des variantes de realisation 
supptementaires, de telecharger, mettre a jour et/ou supprimer des applications 
10 ou parties d'applications enregistrees dans la carte a puce (fichiers, 
programmes, scripts, etc.), via le reseau Internet et les noeuds de 
communication. 

Toutes ces operations peuvent s'effectuer dans de tres bonnes 
conditions de securite, du fait de la transparence precitee de Tenceinte 

15 securisee vis-a-vis du reseau Internet. 

L'invention a done pour objet principal un terminal muni d*une enceinte 
securisee destinee a communiquer avec au moins un serveur de type "WEB'*, 
via un reseau de type Internet, selon un premier protocole de communication de 
type Internet, ladite enceinte securisee comprenant au moins un lecteur de carte 

20 a puce, ladite carte a puce stockant au moins une application logicielle, 
caracterise en ce que ledit terminal comprend une partie non securisee 
comprenant au moins un premier module dit premier noeud de communication, 
ladite enceinte securisee comprend au moins un deuxieme module dit deuxieme 
noeud de communication et ladite carte a puce comprend au moins un troisieme 

25 module dit troisieme noeud de communication, en ce que lesdits noeuds de 
communication comprennent des premiere, deuxieme et troisieme piles 
protocolaires, respectivement, comprenant chacune un nombre determine de 
couches logicielles de communication dites standards et des premiere, 
deuxieme et troisieme pieces de logiciel specifique, respectivement, 

30 comprenant chacune au moins une premiere entite logicielle, lesdites premieres 
entites logicielles etant appariees deux a deux, en ce que ledit premier noeud 
autorise au moins des communications entre ledit terminal et ledit 
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serveur "WEB", selon ledit premier protocole de communication de type Internet, 
en ce que lesdites premieres entiles desdites premiere et deuxieme pieces de 
logiciel specifique autorisent I'etablissement d'une session d*echanges de 
donnees bilateraux entre ledit terminal et la dite enceinte securisee, selon un 
deuxieme protocole de comnnunication determine, en ce que lesdites premieres 
entites desdites deuxieme et troisieme pieces de logiciel specifique autorisent 
au moins i'etablissement d'une session d'echanges de donnees bilateraux entre 
la dite enceinte securisee et ladite carte a puce, via ledit lecteur de carte a puce, 
selon un troisieme protocole de communication determine, de maniere a pouvoir 
mettre en relation au moins une desdites applications logicielles de la carte a 
puce avec ledit serveur de type "WEB". 

Llnvention va maintenant etre decrite de fafon plus detaillee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1 illustre schematiquement un exemple de terminal selon 

Tart connu comprenant une enceinte securisee munie d'un lecteur de 

carte a puce et un clavier ; 

la figure 2 illustre de fa^on generale Tarchitecture logique d'un 

terminal selon I'art connu comprenant un lecteur de carte a puce et 

communiquant avec un serveur "WEB" via le reseau Internet ; 

la figure 3 illustre schematiquement un exemple d'architecture 

generale selon Tinvention permettant des communications, via le reseau 

Internet, entre un serveur eloigne, dit marchand. et un terminal muni 

d'une enceinte securisee comprenant un lecteur de carte a puce, un 

clavier et d'autres ressources informatiques ; 

la figure 4 illustre I'architecture logique de modules permettant les 

communications entre I'enceinte securisee du terminal de la figure 3 et 

la carte a puce ; et 

la figure 5 illustre un mode de realisation particulier de 

I'architecture logique de la carte a puce. 

On va maintenant decrire un exemple de realisation de terminal a 
enceinte securisee conforme a invention et I'architecture de systeme de 
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communication entre ce terminal et un serveur dit "marchand", par reference a 
la figure 3. 

Le terminal, desormais reference 5, peut etre realise, comma il a ete 
indique, a base d'un micro-ordinateur ou d'un appareil similaire. II comprend un 
certain nombre d'elements classiques : microprocesseur, memoires vive et 
morte, memoire de masse (disque dur. etc.), etc. qui ne sont pas representes et 
sont bien connus de THomme de Metier. Par contre, dans {'application propre a 
rinvention, le terminal 5 comprend une enceinte 6, securisee par des moyens 
physiques et logiques. connus en soi. Cette enceinte securisee 6 comprend des 
elements communs a I'art connu, mais aussi des elements specifiques a 
rinvention et qui seront precises ci-apres. Elle comprend tout d'abord, comme 
dans I'art connu, un clavier 62, son gestionnaire 620, ou "handler" selon la 
terminologie anglo-saxonne, et un lecteur de carte a puce 7. 

Le terminal 5 est connecte a un serveur eloigne 4 via le reseau 
Internet Rl ou tout reseau de ce type (intranet, extranet). Comme dans le cas de 
la figure 2, il comprend done tous les elements logiques et materiels permettant 
de communiquer selon un des protocoles utilises sur le reseau Internet, 
notamment le protocole "HTTP/TCP-IP". II est done inutile de re-decrire ces 
elements, sauf a mentionner qu'il comprend un navigateur de type "WEB*' 
reference 51. Ce navigateur 51 permet notamment de poser des requetes vers 
le serveur 4. II constitue une des applications presentes dans le terminal 5, 
celui-ci pouvant en effet en comporter une pluralite. 

Selon une premiere caracteristique importante de rinvention, les 
applications specifiques de I'application marchande ont migre vers le serveur 4. 
Ce dernier comprend done notamment un serveur "HTTP" proprement dit 40 et 
les applications marchandes precitees, enregistrees dans des moyens de 
memoires 41. 

Selon une autre caracteristique importante de rinvention, le terminal 
comprend un premier module specifique 50, que I'on appellera premier noeud de 
communication ou "nceud de communication terminal". Ce module 50 comprend 
des moyens classiques de communication, notamment les piles protocolaires 



decrites en relation avec la figure 2, mais aussi des elements specifiques qui 
seront decrits ulterieurement. 

Selon une autre caracteristique importante encore, i'enceinte 
securisee 6 comprend aussi un module specifique 60, que Ton appellera 
deuxieme noeud de communication ou "noeud de communication enceinte". 

Le premier noeud de communication, 50, permet de faire communiquer 
les serveurs du reseau R/, par exemple te serveur 4, ainsi que les applications 
presentes dans la partie non securisee du terminal 5 (par exemple le 
navigateur "WEB" 51) avec les elements presents dans I'enceinte securisee 6. 
notamment le lecteur de carte a puce 7 et la carte a puce 8, via le deuxieme 
noeud de communication 60. 

L'enceinte securisee 6 comprend un serveur "HTTP" 61, que Ton 
appellera serveur "HTTP enceinte", dispose entre le deuxieme noeud de 
communication 60 et le clavier 62. Ce dernier constitue I'une des ressources 
informatiques de I'enceinte securisee 6. Cette derniere, comme il a ete indique 
dans le preambule de la presente description, peut comprendre des ressources 
supplementaires 1 a /. representees sous la reference unique 63. II peut s'agir, 
par exemple, de dispositifs d'authentification biometriques, d'un coprocesseur 
ou d*un interpreteur externe. La ou les ressource(s) 63 est (sont) egalement 
connectee(s) au serveur "HTTP" 61 , de maniere similaire au clavier 62. 

Le serveur "HTTP" 61 et egalement connecte au lecteur de carte a 

puce 7. 

Le noeud de communication 60 permet d'aiguiller les requetes du 
terminal 5 vers la carte a puce 8, via le lecteur de carte a puce 7, de diriger, en 
sens inverse, les requetes de la carte a puce 8, soit vers le serveur "HTTP" 61 , 
soit vers le terminal 5. via le noeud de communication 50. 

Selon un aspect important de I'invention. le serveur "HTTP" 61 permet a 
la carte a puce 8, et uniquement a celle-ci, d'utiliser les ressources, 62 a 63, de 
Tenceinte securisee 6. 

L'impossibilite d'acceder aux informations du clavier 62 ou des autres 
ressources 63, autrement qu'en passant par la carte a puce 8, qui joue un role 
d'intermediaire, est due a plusieurs facteurs : 



a/ I'enceinte 6 est physiquement securisee (impossibilite physique 
"d'espionner" les elements) ; 

b/ la programmation du noeud 60 est telle que celui-ci empeche tout routage 
de donnees provenant de i'exterieur vers I'entite "HTTP enceinte" 61, le 
noeud 60 etant par ailleurs protege, puisque situe a I'interieur de I'enceinte 
securisee 6 ; et 

cl la programmation de I'entite "HTTP enceinte" 61 est telle que cette 
derniere n'accepte pas de requetes autres que celles emanant de la carte a 
puce 8. ce serveur 61 etant aussi protege, puisque egalement situe a 
I'interieur de I'enceinte securisee 6. 

Si le point a/ est, en sol, commun a I'art connu et a I'invention, les 

points b/ et c/ constituent des caracteristiques specifiques et avantageuses de 

invention. 

On va maintenant decrire de fa?on plus detaillee comment s'effectuent 
les communications entre le reseau Internet Rl et les elements de la partie non 
securisee du terminal 5, entre ces derniers et ceux de I'enceinte securisee 6, 
entre les elements de I'enceinte securisee 6. et entre ces derniers et la carte a 
puce 8, via le lecteur de carte a puce 7. 

Selon I'une des caracteristiques principales de I'invention, toutes ces 
communications s'effectuent selon un mode que I'on qualifiera "d'homogene". 
tout a la fois compatible avec les protocoles Internet, par utilisation d'adresse de 
type standard "URL", et conservant les protocoles normalises de 
communication, notamment entre la carte a puce 8 et le lecteur de carte a 
puce 7 (c'est-a-dire conformes aux normes ISO 7816 precitees). 

Les communications entre le navigateur "WEB" 51 et le serveur 
"marchand" A ne posent pas de problemes particuliers et peuvent s'effectuer 
normalement selon le protocole "HTTP", par utilisation de couches protocolaires 
classiques (voir figure 2) et d'un adressage "URL". Par centre, comme il a ete 
rappele, dans I'art connu. il n'en est pas de meme entre les elements non 
securises et securises d'un terminal (figure 1:1): communications 
habituellement effectuees en mode RS232 ; ni entre les elements de I'enceinte 
securisee 6 et la carte a puce 8, via le lecteur 7. Dans ce dernier cas, comme il 



16 

a ete explicite en regard de la figure 2, tes communications s'effectuent, certes 
par mise en oeuvre de couches protocolaires, mais a I'aide d'un jeu d'ordres 
"APDU", conformement a la norme ISO 7816-3 precitee, done aussi de fa^on 
incompatible avec un protocole de type Internet. 

Aussi, I'invention propose des dispositions specifiques permettant 
d'unifier les communications, tout en conservant la standardisation des elements 
entrant en jeu dans les communications et en ne conduisant qu'a des 
modifications mineures. 

On va tout d'abord detainer les modifications a apporter a Tenceinte 
securisee 6 et a la carte a puce 8, pour pouvoir assurer des communications 
entre ces deux entites, de fagon conforme a I'invention. 

Selon une caracteristique importante de I'invention, on munit la carte a 
puce 8 d'un module specifique constituant un troisieme noeud de 
communication 80 et un serveur "HTTP" 81, que I'on appellera ci-apres 
respectivement "noeud de communication carte" et "serveur HTTP de carte". La 
ou les n application(s) presente(s) dans la carte a puce 8. A) a An, sont 
connectees par une premiere face du serveur "HTTP" 81. Par ces dispositions, 
la carte a puce 8 est transformee en^serveur eVou client "WEB'* pour I'enceinte 
securisee 6 et peut etre "adressee" par une adresse "URL". 

Cette architecture est obtenue, selon {'invention, essentiellement en 
implantant une premiere couche de protocole de communication specifique dans 
la carte a puce 8. De meme, une deuxieme couche de protocole de 
communication specifique, formant le pendant de la premiere, est implantee 
dans I'enceinte securisee 6. 

En ce qui concerne les echanges entre carte a puce 8 et enceinte 
securisee 6, le schema fonctionnel de la figure 3 peut etre represents par 
I'architecture logique^llustree -par la figure 4. 

Dans cette architecture, on retrouve les couches protocolaires de I'art 
connu, comme illustre par la figure 2, qui jouent les memes roles et portent les 
memes references. II est done inutile de les re-decrire. 
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Par contre, on prevoit, de part et d'autre, c'est-a-dire dans I'enceinte 
securisee 6 et dans la carte a puce 8, deux couches de protocoles specifiques 
supplementaires : 64 et 84, respectivement. 

Dans I'enceinte securisee 6, la couche specifique 64 s'interface aux 
couches protocoiaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CCi et CC2, via la couche de multiplexage 13. La couche 
specifique 64 permet le transfert de paquets de donnees de et vers la carte a 
puce 8. En outre, elle adapte les applications existantes pour des utilisations 
mettant en oeuvre la carte a puce 8, sans devoir les re-ecrire. 

Du cote de la carte a puce 8, on retrouve une organisation tout a fait 
similaire constituee par une instance supplementaire de la couche specif! que, 
referencee 84, pendant de la couche 64. 

De fagon plus precise, les couches specifiques, 64 et 84, sont 
subdivisees en trois elements logiciels principaux : 

un module, 640 ou 840, de transfert de blocs d'informations entre 
les couches 13 et 23. via les couches conventionnelles CCi. CC2, CC*1 
et CC'2 ; 

une ou plusieurs pieces de logiciel, dites "agents intelligents", 641 
ou 841, qui realisent. par example, des fonctions de conversion de protocoles ; 

et un module de gestion de la configuration specifique, 642 et 842. 
respectivement, module qui peut etre assimile a un agent intelligent particulier. 

On retrouve done, dans I'enceinte securisee 6 et la carte a puce 8, une 
pile protocolaire de communication entre les deux entites. 

Les couches de niveau deux (couches de lien de donnees), CC2 
et CC'2, assurent les echanges entre la carte a puce 8 et I'enceinte securisee 6. 
Ces couches sont responsables de la detection et I'eventuelle correction 
d'erreurs de transmission, Les differents protocoles rappeles sont utilisables a 
cette fin (recommandation ETSI GSM 11.11 ; le protocole defini par la 
norme ISO 7816-3, en mode caractere T=0 ou en mode bloc T=1 ; ou le 
protocole defini par la norme ISO 3309. en mode trame "HDLC"). II a ete indique 
que, dans le cadre de I'invention. on utilise de preference le protocole 
ISO 7816-3, en mode bloc. 
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De fagon connue en soi. a chaque couche de protocole il est associe un 
certain nombre de primitives qui permettent les echanges de donnees entre 
couches de meme niveau et d'une couche a I'autre. A titre d'exemple, les 
primitives associees a la couche de niveau deux sont du type "demands de 
donnees" {"Data. request*) et "envoi de donnees" par la carte C Data. response"), 
ainsi que "confirmation de donnees" {''Data, con firm'*), etc. 

De fa?on plus particuliere, les couches specifiques 64 et 84 sont 
chargees du dialogue entre la carte a puce 8 et I'hote, c'est-a-dire I'enceinte 
securisee 6. Elles permettent aussi la mise en place d'une configuration adaptee 
pour remission et/ou la reception de paquets de donnees. 

Comme il a ete indique ci-dessus, les couches comprennent trois 
entites distinctes. 

La premiere entite. les modules 640 ou 840, est essentiellement 
constituee par un multiplexeur logiciel. Elle permet I'echange d'informations 
entre la carte a puce 8 et le terminal hote 6, sous la forme d'unites de donnees 
de protocole. Elle joue un role similaire a celui d'un commutateur de paquets de 
donnees. Ces unites sont emises ou regues via la couche de niveau 2 (couche 
de liens de donnees). Ce protocole^^^particulier de communication permet de 
mettre en communication au moins une paire d' "agents intelligents". Le premier 
agent de chaque paire, 641, est situe dans la couche 64, cote enceinte 
securisee 6, le second, 841. est situe dans la couche 84, cote carte a puce 8. 
Une liaison entre deux "agents intelligents", est associee a une session. Une 
session est un echange de donnees bidirectionnel entre ces deux agents. 

Un agent intelligent peut realiser tout ou partie des fonctions des 
couches de niveau trois et quatre, en fonction de la configuration mise en oeuvre 
par I'enceinte securisee 6. 

Un agent intelligent particulier est identifie avantageusement par un 
nombre entier, par exemple sur 16 bits (nombre compris entre 0 et 6535). Get 
identificateur est utilise, par exemple, dans une unite de donnee de protocole 
constituent une reference de destination et une reference de source. 

II existe deux grandes categories d'agents intelligents : les agents de 
type "serveur", qui sont identifies par une reference fixe, et les agents de type 
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"client", qui sont identifies par une reference variable, delivree par le module de 
gestion de configuration, 642 ou 842. 

Le processus d'ouverture d'une session est habituellement le suivant : 
un agent intelligent de type "client" ouvre la session vers un agent intelligent de 
type "serveur". Les modules 642 et 842 gerent des tables (non representees) 
qui contiennent la liste des agents intelligents presents, cote hote 6 et carte a 
puce 8. 

Les agents intelligents. 641 ou 841. sont associes a des proprietes ou 
attributs particuliers. Pour fixer les idees. et a titre d'exemple non limitatif. les 
quatre proprietes suivantes sont associees aux agents intelligents : 
"hote" ; agent localise dans I'enceinte securisee ; 
"carte" : agent localise dans la carte a puce ; 
"client" : agent qui initialise une session ; 
"serveur" ; agent qui regoit une demande de session. 
Les agents intelligents permettent d'echanger des donnees. 
Les modules de gestion de configuration. 642 et 842. respectivement, 
sont assimilables. comme il a ete indique. a des agents intelligents particuliers. 
Par exemple. le module 642, cote hote 6. gere notamment des informations 
relatives a la configuration de I'enceinte securisee 6 (modes de fonctionnement). 
liste des autres agents presents, etc. Le module 842. cote carte a puce 8. a des 
fonctions analogues. Ces deux agents peuvent etre mis en communication I'un 
avec I'autre pour etablir une session. 

Selon une caracteristique importante, la carte a puce 8 propose au 
systeme hote. c'est-a-dire a I'enceinte 6, un modele de terminal virtuel. Pour ce 
faire, la carte a puce 8 se comporte comme un serveur et/ou client "WEB". 

De iagon pratique, la carte a puce 8 est avantageusement "adressee" 
par utilisation d'une adresse "URL" definissant un rebouclage sur le terminal 5, 
et plus particulierement sur I'enceinte securisee 6. et non un pointage sur un 
serveur externe. tel le serveur 4. A titre d'exemple, la structure de cet "URL" est 
habituellement la suivante : 

http://1 27.0.0. 1:8080 (1)ou 
http;//localhost:8080 (Ibis) 



20 

dans laquelle 127.0,0.1 est I'adresse "IP" de rebouclage (''localhosf etant la 
traduction litterale de 127.0.0.1) et 8080 est le numero de port. Uadresse "URL" 
des ressources 62 et/ou 63 pourrait etre completee par un suffixe du type "/xxx". 
Par example, le module de gestion 620 du clavier 62 pourrait avoir comme 
adresse "URL" la suivante : 

http://iocalhost:8080/kb (2) 

L' architecture logique permettant des communications entre le 
terminal 5 proprement dit (entre les noeuds 50 et 60). c'est-a-dire les elements 
non securises de celui-ci et I'enceinte securisee 6 est similaire a celle 
representee sur la figure 4. En consequence, des sessions vont pouvoir etre 
etablies entre les noeuds de communication 50 et 60 conformement au schema 
general qui vient d'etre decrit. L'enceinte securisee va notamment pouvoir etre 
adressee par une adresse "URL", sous le meme numero de port que la carte a 
puce, soil 8080 dans I'exemple decrit. 

Le noeud de communication 50 permet aussi au terminal 5 de 
communiquer avec le reseau Internet RL Aussi, outre les proprietes associees 
aux agents intelligents qui ont ete enumerees ci-dessus, il existe egalement les 
deux proprietes suivantes : 

"local" : agent ne communiquant pas avec le reseau ; 
"reseau" : agent communiquant avec le reseau ; 

Le terminal 5, en sa globalite, est adresse par la meme adresse "IP" 
que ci-dessus. II heberge au moins une application dite de terminal, 
avantageusement le navigateur "WEB" 51. Celui-ci est associe a un port 
particulier. 

A titre d'exemple, par une technique de page "WEB" et d'hyperliens, un 
utiiisateur (non represents) peut choisir un produit ou un service parmi ceux 
disponibles et transmettre la requete au serveur marchand 4. 

Outre la fonction serveur-client "WEB" offerte par la carte a puce 8, 
selon un autre aspect important de I'invention, il est inclus dans celle-ci un 
mecanisme similaire a la fonction dite "CGI" (pour "Common Gateway Interface") 
implantee dans les serveurs "WEB" classique. 
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Avant de decrire un example d'une architecture conforms a I'invention, 
permettant de realiser une fonction de ce type au sein meme de la carte a 
puce 8, il est utile de rappeler les principales caracteristiques d'un mode de 
fonctionnement "CGI". 

Le "CGI" est une specification de mise en oeuvre, depuis un 
serveur "WEB", d'applications ecrites pour les systemes d'exploitation "UNIX" 
(marque deposee). "DOS", ou "WINDOWS" (marque deposes). A titre 
d'exemple, pour le systeme d'exploitation "UNIX", la specification est "CGI 1.1" 
et pour le systeme d'exploitation "WINDOWS 95". la specification est "CGI 1.3". 

Toujours a titre d'exemple. une requete "HTTP" pour une 
adresse "URL", du type . 

"http://www.host.com/cgi-bin/xxx" (3). 
dans laquelle "host" se refere a un systeme hote (generalement eloigns), est 
interpretee par un serveur "WEB" comme I'execution d'un script de commande. 
de type "CGI" nomme "xxx" et present dans le repertoire "cgi-bin" de ce systeme 
hote. Bien que le nom du repertoire puisse elre a priori quelconque. par 
convention, c'est le nom donne au repertoire stockant les scripts de type "CGI". 
Un script sst une suite d'instructions du systeme d'exploitation du systeme hote 
dont le resultat final est transmis au navigateur "WEB" emetteur de la requete 
precitee ou a toute autre application sollicitant le service, comme un serveur 
marchand. Differents langages peuvent etre utilises pour ecrire ce script, par 
exemple le langage "PERL" (marque deposee). 

De fa?on pratique, la requete est habituellement affichee sur un ecran 
informatique sous la forme d'un formulaire compris dans une page "HTML". Le 
langage "HTML" permet de poster un formulaire a une adresse "URL". Le 
formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont 
remplis par un utilisateur a I'aide des moyens de saisie habituels : clavier pour 
le texte. souris pour les cases a cocher ou les boutons dits "radio", etc. Le 
contenu du formulaire (ainsi qu'eventuellement des informations et instructions 
dites "cachees") est emis a destination du serveur "WEB". Le code "HTML" de 
la page decrit la structure materielle du formulaire (cadre, graphisme. couleur. et 
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tout autre attribut), ainsi que la structure des champs de donnees a saisir (nom, 
longueur, type de donnees, etc.). 

La transmission peut s'effectuer selon deux types de formats "HTTP" 
principaux. Un premier format utilise la methode dite "POST" et un second la 
methode dite "GET". Une information de type de format est presente dans le 
code de la page formulaire. 

Ce mecanisme n'est cependant pas directement transposable a une 
carte a puce, meme si ceile-ci offre la fonctionnalite serveur "WEB" 
conformement a I'une des caracteristiques de I'lnvention. 

On va maintenant decrire un exemple d'architecture permettant 
d'activer une application quelconque, de type conventionnel. via un serveur 
"WEB" sur la carte a puce, par reference a la figure 5. 

Le serveur marchand 4 active une requete "HTTP" de type "GET" a une 
adresse "URL" qui peut se presenter de la fagon suivante : 

"http://@carte:8080/xxx.8080/cgi-bin/le_cgi ? parami +param2" (4), 
dans laquelle "@carte" est I'adresse "IP" du terminal supportant la carte a puce 
(par exemple I'adresse de rebouciage "127.0.01" de la relation (1)), "le-cgi" est 
un script "CGI" particulier a executer sur la carte a puce 8 et "parami" et 
param2" des parametres a passer au script precite. La requete est tout d'abord 
transmise a Tenceinte securisee 6. via les noeuds de communication 50 et 60 
(figure 3). 

Une session s'etablit entre le terminal et le lecteur de carte a puce. 
Ensuite une autre session s'etablit entre une paire d'agents intelligents, 641 et 
841, localises dans les couches specifiques de Tenceinte securisee 6 et de la 
carte a puce 8, respectivement 64 et 84. Les donnees traversent alors le 
multiplexeur de paquets 640 de la couche protocolaire de communication 
specifique 64. Elles traversent ensuite les couches protocolaires classiques 
(voir figure 2). Cependant. pour mieux mettre en evidence certains aspects 
specifiques de Tinvention. qui vont etre explicites ci-apres, ces couches sent 
divisees en deux parties sur la figure 5 : un gestionnaire d'ordres "APDU" 65a et 
des couches protocolaires basses 65b (normes ISO 7816-3). 
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De meme, dans la carte a puce 8, elles traversent les couches 
protocolaires basses, referencees 85b, et le gestionnaire d'ordres "APDU" cote 
carte, reference 85a, puis le multiplexeur de paquets 840, pour etre re?ues par 
I'agent intelligent 841, que Ton appellera "agent WEB". 

II convient de remarquer que les donnees adressees a I'agent 
"WEB" 841 sont transporlees, de fagon conventionnelle en soi, sous formes 
d'ordres "APDU" destines a Tapplicatlon particuliere "Multiplexeur de 
paquets" 840. Le gestionnaire d'ordres "APDU" 85a selectionne cette 
application de maniere tout a fait similaire aux autres applications presentes 
dans la carte a puce 8, a A^. En d'autres termes, le multiplexeur de 
paquets 840 est vu par le gestionnaire d'ordres "APDU" 85a comme une 
application carte ordinaire. 

La requete "HTTP" est alors analysee par I'agent "WEB" 841 qui 
detecte une reference a un repertoire particulier, que I'on appellera cl-apres par 
convention "cgi-smart". d'une part, et a une application particuliere, par 
exemple A,. Le chemin complet est done, en ('occurrence, "cgi-smart/A ". 

Selon une caracteristique importante du precede de I'invention, I'entite 
ci-dessus designe un script particulier associe a une application egalement 
particuliere. 

Selon un autre aspect de I'invention, on implante dans la carte a puce 8 
des agents intelligents particuliers, que I'on appellera ci-apres "Agents 
traducteurs de script" ou de fa?on abregee "ATS". Le script est alors interprets 
par un des agents intelligents. Cette traduction peut etre realisee de differentes 
manieres : 

a/ par I'agent "WEB" 841 lui-meme, qui est dote dans ce cas d'une double 
capacite ; 

b/ par un agent script unique capable de traduire I'ensemble des scripts 
presents dans la carte a puce 8 ; 

c/ par un agent de script dedie que I'on appellera "ATSD" ci-apres (un par 
script) ; ou 

d/ par un agent "APDU" 850a du gestionnaire d'ordres "APDU" 85a, qui est 
dote, dans ce cas, d'une double capacite. 



24 

L'agent "APDU" 850a est une composante de la couche gestionnaire 
d'ordres "APDU" 85a. Cette derniere est une couche capable de centraliser tous 
les ordres "APDU" emis et/ou re?us par le systeme, de selectionner des 
applications, parmi a mais egatement d'offrir une interface de type agent 
intelligent. Elle est done capable, selon Tune des caracteristiques de Tinvention 
de communiquer avec tous les agents intelligents (via des sessions), que ces 
agents soient localises dans Tenceinte 6 ou la carte a puce 8. 

Dans le cas c/ ci-dessus, une session est ouverte entre l'agent 
"WEB" 841 et Tun des agents "ATSD". 

La figure 5 illustre un exemple d'architecture pour laquelle les agents 
traducteurs sont du type "ATSD". lis sont references /\rSi a ATSn et associes 
aux applications a A^, L'application selectionnee etant supposee etre 
I'application A., la session s*etablit entre l'agent "WEB" 841 et Pagent ATS.. 

Un agent traducteur de script genere une suite d'ordres "APDU". Une 
session est ouverte entre l'agent traducteur, par exemple Tagent ATS^, et Tagent 
"APDU" 850a. Les ordres sont alors emis vers l'agent "APDU" 850a. Le 
gestionnaire d'ordres "APDU" 85a seleotionne l'application "CGA" /\. et lui 
transmet les ordres "APDU". ordres Iraduits et done conventionneis. qu'elle est 
en mesure de comprendre. Cette application est done correctement activee, 
sans avoir a la modifier ou a la reecrire. 

Les reponses de rapplication A- sont transmises au gestionnaire 
d'ordres "APDU" 85a, a l'agent "APDU" 850a, puis de nouveau a l'agent ATS^ (et 
de fagon plus generale a l'agent traducteur de script). 

Les differents cheminements sont representes symboliquement sur la 
figure 5 par des traits pleins reliant les blocs fonctionnels, ou en pointilles a 
rinterieur de ces blocs. 

Pour fixer les idees et sans que cela soit limitatif de- la portee de la 
presente invention, la technique d'adressage etant desormais definie dans sa 
generalite, on va maintenant detainer ci-dessous divers routages possibles, que 
Ton appellera cas d'utilisation et que Ton referencera CU-a? : 

CU-1 : communication entre le serveur marchand 4 et la carte a puce 8. 
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Pour ce faire, une adresse '^URL" conforme a (1) est utilisee. Dans ce 
cas, il n'est pas necessaire d'utiliser le clavier 62. La requete, transmise via le 
reseau Internet Rl, arrive sur le nceud de communication 50. Celui-ci identifie le 
port associe a la carte a puce, c'est-a-dire le port 8080. qui est le meme que 
celui de I'enceinte securisee 6. Le noeud de communication 50 achemine la 
requete vers le noeud de communication 60. Dans tous les cas, quelle que soit 
I'adresse "URL", ce dernier achemine le paquet de donnees regues vers la carte 
a puce 8, et plus precisement vers le serveur "HTTP" carte a puce 81, via le 
noeud de communication 80. En dernier lieu, celui-ci active I'une des 
applications de la carte a puce 8. par exemple I'application yAi. 

CU-2 : communication entre deux applications de la carte a puce 8. 

Par exemple, Tapplication veut communiquer avec I'application An- La 
requete emanant de Tapplication A-i est acheminee par le serveur •'HTTP" 81. 
De fa?on pratique, une session s'etablit entre une paire d'agents intelligents 
iocaux a la carte a puce 8, selon le schema qui a ete explicite en regard de la 
figure 4. Le noeud de communication 80 n'entre pas en jeu. II n'y a pas 
d'adaptation de protocole de communication a prevoir. 

CU-3 : communication entre une application carte et I'application 
marchande 41 dans le serveur 4. 

Ce cas peut se produire, notamment, lorsque la carte a puce 8 a regu 
une requete du serveur marchand 4 (cas CU-1). Une application locale a la 
carte a puce 8, par exemple i'application A^, peut etre activee. Une action 
determinee, commandee par la requete re?ue, est alors realisee a I'interieur de 
la carte a puce, par exemple une action de type "CGI", par execution d'un script 
ou tout processus equivalent. Cette action est realisee sous la commande 
d'agents intelligents traducteurs de script, comme il a ete explicite en regard de 
la figure 5. 

En resultat, I'application Ay pose une requete destinee au serveur 4. 
Apres examen de I'adresse "IP", le serveur "HTTP" 81 oriente la requete vers le 
noeud de communication 80. II s'etablit une session entre la carte a puce 8 et 
Tenceinte securisee 6, plus precisement entre les noeuds de communication 60 
et 80, selon le schema qui a ete decrit en regard de la figure 4. De meme, le 
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noeud de communication 60, apres examen de Tadresse "IP", transmet la 
requete au noeud de communication 50. Ce dernier, apres examen de 
I'adresse "IP", transmet a son tour la requete, via le reseau Internet R/, vers sa 
destination finalei c'est-a-dire vers le serveur 4. 

Le processus peut comporter plusieurs aller et retour entre la carte a 
puce 8 et le serveur 4. pendant le temps d'une transaction. Lorsque le 
processus est termine (fin du "CGI" par exemple), la reponse de la carte a puce 
est transmise au serveur marchand 4, via notamment les noeuds successifs de 
communication 80, 60 et 50. 

CU-4 : communication entre une "application carte" et une "application 
terminal". 

A titre d'exemple, I'application Ai veut par exemple communiquer avec 
un gestionnaire d'impression (non represente) du terminal et pose une requete 
en ce sens. Apres examen de I'adresse "IP" et du numero de port, le serveur 
"HTTP" 81 oriente la requete vers le noeud de communication 80. La requete 
suit alors le meme chemin que dans te cas CU-3, jusqu'a ce qu'elle atteigne le 
noeud de communication 50. Ce dernier, apres examen de I'adresse "IP" et du 
numero de port, oriente la requete vers rapplieation terminal adressee, par 
exemple le gestionnaire d'impression. 

CU-5 : communication entre une "application carte'* et une ressource de 
I'enceinte securisee. 

On suppose tout d'abord, dans ce cas d'utilisation, que la carte a 
puce 8 est en mode "esclave" par rapport au serveur marchand 4 et que celui-ci 
a emis une requete a destination de la carte a puce 8. Cette requete est traitee 
de la fagon explicitee par les cas CU-1 et CU-3. II s'execute par exemple un 
"CGI marchand" a Tinterieur de la carte a puce 8, de la maniere qui a ete decrite 
en regard de la figure 5. Ce script s'execute en activant I'une des applications, 
par exemple A/, a I'aide d*un des agents traducteurs de script, par exemple ATSi. 
On suppose que le CGI marchand a besoin d'informations en provenance du 
clavier 62 (mot de passe par exemple) ou d'autres informations 
d'authentification (en provenance d'un dispositif biometrique constituent I'une 
des ressources 63). Le CGI en question doit etre execute avec un adressage 
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"URL" particulier. L'application A emet une requete dont I'adresse est par 
example celle donnee par (2) ci-dessus. La presence du suffixe "/kb" indique au 
noeud de communication 60 qu'il faut reboucler la requete vers le serveur 
"HTTP" 61 qui a son tour active le gestionnaire 620 de clavier 62, et recupere 
les informations attendues (saisie d'un mot de passe par exemple). La reponse 
de la requete est transmise, par le meme chemin, mais en sens inverse vers la 
carte a puce 8. 

La reponse de la requete du serveur marchand 4 est alors retransmise 
a celui-ci. Un dialogue a plusieurs temps peut s'instaurer de maniere similaire 
au cas CU-3. 

Plusieurs CGI peuvent etre executes pendant le temps d'une 
transaction. 

Pour fixer les idees, un premier "CGI marchand" peut avoir pour resultat 
I'affichage sur un ecran compris dans I'enceinte securisee 6 (I'une des 
ressources representees sous la reference unique 63) d'un message invitant un 
utilisateur a composer un code et affichant un montant. Un deuxieme CGI lit par 
exemple des informations transmises par le clavier 62. Un troisieme CGI peut 
avoir pour resultat sur ce meme organe de visualisation d'un message du type 
"CODE CORRECT" ou tout message similaire. 

CU-6 : communication entre le terminal et une des ressources de 
I'enceinte securisee. 

A titre d'exemple, une application du terminal 5 (dans sa partie non 
securisee), par exemple le navigateur "WEB" 51, desire communlquer avec 
I'une des ressources securisees, par exemple avec le clavier 62. et emet une 
requete en ce sens. Le noeud de communication 50 examine I'adresse "URL", 
identifie le numero de port de I'enceinte securisee 6 et transmet la requete a 
celle-ci. Le noeud de communication 60. du fait de sa programmation. oriente 
systematiquement les requetes regues, meme si elles sont destinees a I'une des 
ressources internes a I'enceinte securisee 6. vers la carte a puce 8. A partir de 
ce stade, la requete suit un chemin similaire au cas CU-1. C'est la carte a 
puce 8 qui determine s'il y lieu de retransmettre la requete vers la ressource 
securisee initialement adressee, eventuellement en la modifiant. La decision 
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peut etre le resultat d'une procedure d'identification mettant en jeu rexamen de 
donnees de securite enregistrees dans la carte a puce, notamment dans una 
memoire de type a lecture seule, eventuellement sous forme chiffree. Comme 
dans le cas CU-4, un element externe a I'enceinte securisee 6 n'a done jamais 
acces directement aux ressources securisees. 

Cette derniere caracteristique permet des mises a jour de logiciels 
residents dans I'enceinte securisee 6, des ajouts de logiciels ou des 
suppressions, au moins partielles, de ces logiciels, de fagon plus fiable que 
dans I'art connu. En effet. il est d'usage d'authentifier des modifications de cette 
nature a partir d'une cle enfouie dans le logiciel de I'enceinte securisee 6. 

Puisque seule la carte a puce 8 peut acceder de I'exterieur aux 
ressources protegees de I'enceinte securisee 6, le telechargement de 
ressources logicielles peut done s'effectuer a partir d'un serveur Internet, par 
rintermediaire de la carte a puce, tout en conservant un tres^ grand degre de 
securite. II suffit que les donnees telechargees, si elles sont sensibles, soient 
convenablement chiffrees. en faisant usage d'un algorithme robuste et/ou d'une 
cle de chiffrage suffisamment longue, Du fait de la fonction d'intermediaire jouee 
par la carte a puce^S, 1e mecanisme mis en oeuvre dans I'invention est a priori 
plus fort que celui d'un simple enfouissement de cle dans un organe de memoire 
(non represente) de I'enceinte securisee 6. 

On peut egalement modifier le contenu des ressources logicielles de 
I'enceinte securisee 6 directement a partir d'une carte a puce 8, en 
telechargeant des pieces de logiciel enregistrees dans celle-ci, Le volume de 
logiciel ainsi telecharge est cependant limite par les ressources propres de la 
carte a puce (capacite de memoire), ce qui n'est pas le cas a priori d'un 
telechargement par reseau Internet a partir d'un serveur "WEB", le serveur 
pouvant etre dote de ressources informatiques importantes, Le temps de 
telechargement est naturellement dependant de la quantite de logiciel a 
telecharger. mais I'utilisation de modems rapides et/ou de lignes de 
communication a haut debit est de nature a maintenir ce temps dans des limites 
tout a fait raisonnables pour les applications envisagees. 
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A la lecture de ce qui precede, on constate aisement que invention 
atteint bien les buts qu'elle s'est fixes. 

Elle permet notamment, tout en conservant la possibilite d'utiliser des 
composants classiques et des modes de communication normalises, notamment 
5 entre I'encelnte securisee et la carte a puce, via le lecteur, un adressage et des 
communications compatibles avec le protocole Internet "HTTP'*. Elle transforme 
la carte a puce en serveur-client "WEB", capable d'effectuer des operations de 
type "CGI". Elle permet notamment un adressage direct et interactif de la carte a 
puce, a partir d'un serveur "WEB", via le reseau Internet, ou en sens contraire. 

10 Elle ne necessite aucune application spectfique marchande sur le terminal lui- 
meme et sur Tenceinte securisee. Elle offre une tres grande souplesse et 
s*adapte aisement a de nombreux domaines d'application. Elle n'entralne que 
des modifications mineures des composants utilises, modifications qui se 
resument essentiellement a I'implantation de pieces de logiciel specifiques. 

15 etant entendu que le mot "specifique" n'indique pas une dependance vis-a-vis 
des applications traitees. Notamment les applications residentes dans la carte a 
puce restent des applications standards et ne necessitent aucune re-ecriture. 
En outre, les applications specifiques, d'un point de vue "application 
marchandes" sont entierement localisees dans le serveur "WEB" eloigne. Ce 

20 dernier peut en contenir une pluratite. La mise a jour, la suppression de ces 
applications, ainsi que I'ajout de nouvelles applications, sont de ce fait aises. 
Cette caracteristique offre une grande flexibilite. La version des programmes est 
identique pour tous les terminaux qui se connectent sur le serveur. Enfin, la 
securite assuree par I'invention est tres grande. On peut faire appel a des 

25 algorithmes de chiffrage robustes et des cles de grande longueur pour les 
communications sur le reseau Internet. En outre, selon une caracteristique 
importante de Tinvention, toutes les requetes provenant de I'exterieur de 
Tenceinte securisee, que ce soit de la partie non securisee du terminal ou 
directement du reseau Internet, doivent obligatoirement passer par la carte a 

30 puce et restent sous son controle exclusif. Celle-ci decide seule, en fonction, par 
exemple, de donnees de securite residentes, de I'usage qui doit etre fait de ces 
requetes. Or la carte a puce reste la propriete du porteur. 
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II doit etre clair cependant que ['invention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec les 
figures 3 a 5. 

Dans un mode de realisation (non represente) Tenceinte securisee 
pourrait ne contenir qu'un lecteur de carte a puce, la ou les application(s) 
enregistree(s) dans la carte a puce etant autosuffisante(s) pour authentifier le 
porteur et/ou permettre une transaction entre le serveur "WEB" eloigne et la 
carte a puce. Le clavier peut etre omis et remplace par Tune des ressources 
securisees, tel qu'un dispositif biometrique. Enfin, on peut adjoindre au premier 
lecteur de carte a puce un deuxieme lecteur de carte a puce, voire plusieurs. 
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REVENDICATIONS 

1. Terminal muni d'une enceinte secuhsee destinee a communiquer avec au 
moins un serveur de type "WEB", via un reseau de type Internet, selon un 
premier protocole de communication de type Internet, ladite enceinte 
securisee comprenant au moins un lecteur de carte a puce, ladite carte a 
puce stockant au moins une application logicielle, caracterise en ce que ledit 
terminal (5) comprend une partie non securisee comprenant au moins un 
premier module dit premier noeud de communication (50), ladite enceinte 
securisee (6) comprend au moins un deuxieme module dit deuxieme noeud de 
communication (60) et ladite carte a puce (8) comprend au moins un 
troisieme module dit troisieme noeud de communication (80), en ce que 
lesdits noeuds de communication (50, 60. 80) comprennent des premiere, 
deuxieme et troisieme piles prolocolaires. respectivement, comprenant 
chacune un nombre determine de couches logicielles de communication dites 
standards et des premiere, deuxieme et troisieme pieces de logiciel 
specifique (64, 84). respectivement, comprenant chacune au moins une 
premiere entite logicielle (641, 841). lesdites premieres entites logicielles 
etant appariees deux a deux, en ce que ledit premier noeud (50) autorise au 
moins des communications entre ledit terminal (5) et ledit serveur "WEB" (4), 
selon ledit premier protocole de communication de type Internet, en ce que 
lesdites premieres entites desdites premiere et deuxieme pieces de logiciel 
specifique autorisent Tetablissement d'une session d'echanges de donnees 
bilateraux entre ledit terminal (5) et la dite enceinte securisee (6), selon un 
deuxieme protocole de communication determine, en ce que lesdites 
premieres entites (641, 841) desdites deuxieme (64) et troisieme (84) pieces 
de logiciel specifique autorisent au moins I'etablissement d'une session 
d'echanges de donnees bilateraux entre la dite enceinte securisee (6) et 
ladite carte a puce (8), via ledit lecteur de carte a puce, selon un troisieme 
protocole de communication determine, de maniere a pouvoir mettre en 
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relation au moins une desdites applications logicielies (vAi-vA^) de la carte a 
puce (8) avec ledit serveur de type "WEB" (4). 

Terminal selon la revendication 1. caracterise en ce que lesdites premieres 
entites appariees sent constituees de modules logiciels, dits agents 
intelligents (641, 841), etablissant lesdites sessions. 

Terminal selon la revendication 1, caracterise en ce qu*il comprend, dans 
ladite partie non securisee, au moins une application constituee par un 
navigateur de type "WEB" (51), en ce que ledit premier protocole de type 
Internet est le protocole "HTTP/TCP-IP" comporte un adressage de type dit 
"URL", comprenant un element d'adresse Internet dite "IP" et un numero de 
port, pour la selection dudit terminal (5) et d'un element interne a ce 
terminal (5), en ce que ladite premiere entite de ladite piece de logiciel 
specifique dudit premier noeud de communication (50) identifie ledit element 
d'adresse "IP" et ledit numero de port, en ce que, en resultat de ladite 
identification, des donnees re?ues dudit serveur de type "WEB" (4) sont 
aiguillees vers ledit navigateur de type "WEB" (51), selon ledit premier 
protocole de type Internet, ou traduites et transmises vers ledit deuxieme 
noeud de communication (60), selon ledit deuxieme protocole de 
communication determine, dans un premier sens de transmission de 
donnees, et en ce que sur ladite identification, des donnees regues du 
deuxieme noeud de communication (60), sont aiguillees vers ledit navigateur 
de type "WEB" (51) ou vers ledit serveur de type "WEB" (4), selon ledit 
premier protocole de type Internet, dans un second sens de transmission de 
donnees. 

Terminal selon la revendication 3, caracterise en ce que ladite enceinte 
securisee (6) ' comprend en outre au moins un clavier de saisie de 
donnees (62) et au moins un serveur "HTTP" dit d'enceinte (61) dispose entre 
ledit clavier (62) et le dit deuxieme noeud de communication (60), en ce que 
ladite premiere entite (641) de ladite piece de logiciel specifique (64) dudit 
deuxieme noeud de communication (60) identifie ledit element d'adresse "IP" 
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et ledit numero de port, en ce que des donnees regues dudit premier noeud 
de communication (50) sont traduites et toujours transmises vers ledit 
troisieme noeud de communication (80), selon ledit troisieme protocole de 
communication determine, dans un premier sens de transmission de 
5 donnees, et en ce que sur ladite identification, des donnees regues du 

troisieme noeud de communication (80), sont aiguillees vers ledit serveur 
"HTTP" (61) ou traduites et transmises vers ledit premier noeud de 
communication (50), selon ledit deuxieme protocole determine, dans un 
second sens de transmission de donnees. 

10 5. Terminal selon la revendication 4, caracterise en ce que ladite enceinte 
securisee comprend au moins une ressource informatique 
supplementaire (63) connectee audit serveur "HTTP" (61) de I'enceinte 
securisee (6), et en ce que ladite adresse de type "URL" comprenant un 
element supplementaire. ledit serveur "HTTP" (61) selectionne, sur 

15 identification dudit element d'adresse supplementaire, ledit clavier (62) ou 

I'une desdites ressources informatiques supplementaires (63). 

6. Terminal selon la revendication 5, caracterise en ce que ladite ressource 
informatique supplementaire (63) est un dispositif d'authentification 
biometrique. 

20 7. Terminal selon la revendication 4, caracterise en ce que ladite carte a 
puce stocke plusieurs applications logicielles {A^-An), en ce qu'elle comprend 
un serveur "HTTP" dit de carte (81) dispose entre lesdites applications 
logicielles (A^-An) et ledit troisieme nceud (80), et en ce que ledit serveur 
"HTTP" de carte (81) active selectivement au moins Tune desdites 

25 applications logicielles (yAi-yA„) sur reception d'une requete en provenance 

dudit deuxieme nceud (60) ou transmet les requetes emises par lesdites 
applications {A^-An) vers ledit troisieme noeud de communication (80). 

8. Terminal selon la revendication 7, caracterise en ce que ladite carte a 
puce (8) comprend en outre une deuxieme entite logicielle {ATS^-ATSi) apte a 
30 interpreter une suite d'instructions vehiculees par lesdites donnees regues 
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dudit troisieme noeud de communication (80), et a la traduire en une suite 
d'ordres, ladite deuxieme entite logicielle {ATS^-ATSi) cooperant avec lesdites 
applications logicielles {A^'An) et ladite piece de logicielle specifique (84) 
dudit troisieme noeud de communication (80), ladite suite d'instructions 
traduite etant associee a une desdites applications logicielles a activer 
{A^-An) de ladite carte a puce (8). 

9. Terminal selon la revendication 8, caracterise en ce que ladite suite 
d'instructions a interpreter etant constitute par un script, chacune desdites 
deuxiemes entites logicielles est constitute par un module logiciel dit agent 
intelligent traducteur de script {ATS^-ATSi). 

10. Terminal selon la revendication 1, caracterise en ce que ledit serveur de 
type "WEB" (40) stocke une application logicielle dite marchande (41) 
destinee a etre mise en communication interactive avec au moins Tune 
desdites applications logicielles (/\i-/An) de ladite carte a puce (8) au travers 
desdits premier (50). deuxieme (60) et troisieme noeuds (80) de 
communication. ' 
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